HCL Notes and Domino wiki: Domino security: Configuring Microsoft Windows single sign-on for Web clients in an existing IBM Lotus Domino environment

Configuring Microsoft Windows single sign-on for Web clients in an existing IBM Lotus Domino environment

Added by ~Fred Cistumipulings | Edited by ~Fred Cistumipulings on December 19, 2011 | Version 3

Actions ▼

This article is a simplified guide of the steps to configure Microsoft Windows Single Sign-on with IBM Lotus Domino. Using this guide, you can get your environment running in just a few minutes, even if you do not have in-depth knowledge of either the Trust Association Interceptor operation mode or SPNEGO.

ShowTable of Contents

HideTable of Contents

1 Introduction
2 Configuring SSO
3 Conclusion
4 Resources
5 About the author

Introduction

As of version 8.5.1, IBM® Lotus® Domino® started to support Microsoft® Windows® Single Sign-on (SSO) with Windows Integrated Authentication via Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO).

This configuration allows users to connect to Web applications without having to enter their credentials. The authentication process takes place without passing credentials in the network, ensuring that even if sniffing is being attempted in the network, there is nothing to "sniff".

This article is a simplified guide of the steps to configure Microsoft Windows Single Sign-on with Lotus Domino. For more detailed instructions, refer to the Domino wiki article, “Configuring Microsoft Windows single sign-on on IBM WebSphere and Domino platforms."

Figure 1 illustrates the authentication process.

Figure 1. Diagram of the authentication process

Configuring SSO

The steps necessary to configure SSO are few and simple, so in a few minutes we can enable it between Windows and Lotus Domino. To do this, we run the configuration described using the "Internet Sites", by defining a virtual host environment specific to the SSO domain.

We want to have two separate domains of SSO, so as not to adversely affect existing configurations, for example, as shown in figure 2.

Figure 2. Example of two separate SSO domains

In this example, the domain “net2action” allows SSO with Windows, but the domain “shamrock” does not. To allow this, we need to create the respective Web SSO Configuration documents for LtpaToken win (see figure 3) and LtpaTokenNoWin (see figure 4).

Figure 3. Web SSO Configuration document for LtpaTokenWin

Figure 4. Web SSO Configuration document for LtpaTokenNoWin

Now you must create your Domino SSO key or import the WebSphere LTPA Keys (see figure 5), if you use this solution in a complex environment of SSO Domains that includes WebSphere/Domino/Windows.

Figure 5. Keys menu

1. In the AD server with the Support Tools installed, run the command

SETSPN-a HTTP /

and use the FQDN that users will use to reach the Web server; in our case:

SETSPN-to HTTP/mail.net2action.com DominoStart

2. Then, using the command, SETSPN , verify that the configuration is correct; if needed, you can configure multiple FQDNs:

3. Now in the User name field of the Person document (see figure 6), add the full name of your user ID in Windows format, @; in our case, “p.rossi@SHAMEROCK.COM”.

Figure 6. Person document

Of course it is not difficult to create an agent that provides the mapping, but it is more functional to use an assembly line of IBM Directory Integrator, so that this configuration is dynamic and driven by changes in the AD.

4. The configuration is now complete. To verify it is able to connect to a PC in the domain, open a browser and call our Domino server, for example, as shown in figure 7.

Figure 7. Server Login windows in IE

Table 1 shows some flags that help us with the Notes.ini configuration testing (see table 1).

Table 1. Notes.ini flags and their usage

Notes.ini flag	Usage
CONSOLE_LOG_ENABLED=1	Enables logging of all console output <InstallRoot> \ \ <Data Directory> \ \ IBM_Technical_Support \ \ console.log
Debug_SSO_Trace_Level=2	Allows debugging of the SSO token - after a reboot of the HTTP ("restart task http")
DEBUG_HTTP_SERVER_SPNEGO=5	Allows debugging of SPNEGO tokens - after a reboot of the HTTP ("restart task http")
webauth_verbose_trace=1	Enables debugging for the authentication web-resolution mapping of names and DA to external LDAP - with immediate effect
debug_outfile=c:\tmp\Spnegonotes.log	Enables the SPNEGO trace in a file

Supported browsers are Microsoft Internet Explorer versions 6, 7, 8 and Mozilla Firefox 4.5. Google Chrome only supports Lotus iNotes UltraLite for mail only.

Figure 8. Lotus iNotes on Chrome

The trace of the authentication process is as follows:

.12:13:54 AM NOTES.INI contains the following *DEBUG* parameters:
08/25/2011 12:13:54 AM DEBUG_HTTP_SERVER_SPNEGO=5
08/25/2011 12:13:54 AM DEBUG_OUTFILE=c:\tmp\Spnegonotes.log
08/25/2011 12:13:54 AM DEBUG_SSO_TRACE_LEVEL=2
08/25/2011 12:13:54 AM Warning: Debug parameters could impact operation or performance.
08/25/2011 12:13:55 AM Contact your appropriate support vendor.
08/25/2011 12:13:55 AM The Console file is c:\tmp\Spnegonotes.log
08/25/2011 12:13:55 AM Console Logging is ENABLED

08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Success calling native routine AcquireCredentialsHandleW
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Security token format received is SPNEGO NegTokenInit
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Success calling native routine AcceptSecurityContext
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> SSPI security attributes received 0x803, but requested 0x20014
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Success calling native routine QueryContextAttributesW
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Success calling native routine QueryContextAttributesW
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Success calling native routine QueryContextAttributesW
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> User p.rossi@SHAMROCK.COM authenticated by Kerberos service HTTP/mail.net2action.com@SHAMROCK.COM
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Success calling native routine QueryContextAttributesW
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SPNEGO> Authenticated user is p.rossi@SHAMROCK.COM via MSIE 6.0
.
.
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SSO API> *** Getting Single Sign-On Config Data (SECGetSSOConfigData) ***
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SSO API> OrgName specified [net2action].
08/25/2011 12:18:54.00 AM [06A8:000B-0F3C] SSO API> ConfigName specified [LtpaTokenWin].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Retrieved global static cache memory for config [net2action:LtpaTokenWin].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> *** Generating Single Sign-On Token List and retrieving token info (SECTokenListGenerateAndGetTokenInfo) ***
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> OrgName specified [net2action].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> ConfigName specified [LtpaTokenWin].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Retrieved global static cache memory for config [net2action:LtpaTokenWin].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Setting token domain parameter [.net2action.com]
> 08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Creation time not specified, using current time [08/25/2011 12:18:54 AM].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Expiration time not specified, using current time plus config expiration [08/25/2011 12:48:54 AM].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Setting token name parameter [LtpaToken]
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Encoding Domino style Single Sign-On token.
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> -Creation Ticks = 4E5578CE [08/25/2011 12:18:54 AM].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> -Expiration Ticks = 4E557FD6 [08/25/2011 12:48:54 AM].
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> -Username = CN=Paolo Rossi/O=shamrock/C=IT
08/25/2011 12:18:54.01 AM [06A8:000B-0F3C] SSO API> Dumping memory of constructed token [71 bytes].
00000000: 0100 0302 4534 3535 3837 4543 4534 3535 '....4E5578CE4E55'
00000010: 4637 3644 4E43 503D 6F61 6F6C 5220 736F '7FD6CN=Paolo Ros'
00000020: 6973 4F2F 733D 6168 656D 6F72 6B63 432F 'si/O=shamrock/C'
00000030: 493D D954 8711 C966 72D9 BCDF F471 1E56 '=ITY..fIYr_<qtV.'
00000040: C4F7 88E4 EB05 69 'wDd..ki'

Conclusion

You have successfully configured an SSO environment so that all your users logging in to the Windows domain will have access to Lotus Domino applications without having to provide credentials again. This functionality also extends to all applications that have a contract with the Windows domain authentication.

Resources

IBM Lotus Domino and Notes Information Center

Configuring Microsoft Windows single sign-on for IBM Lotus Connections

Configuring single sign-on with an LTPA token on IBM WebSphere and IBM Lotus Domino platforms

About the author

Andrea Fontana currently works as a System Architect, defining, organizing, and configuring complex IBM product-based solutions. In particular he works with WebSphere Portal and its collaborative environment including Domino 8.0.x, 8.5, IBM Connections 3.01, Lotus Quickr 8.0.x, and IBM Sametime, with respect to setting up SSO Kerberos integration solutions and configuring systems with a r-proxy solution with SSL integration. His past experience includes roles as an Application Developer, Database Administrator, and Project Manager in a wide variety of business applications. He graduated from the ITIS Zuccante C., Mestre (Venice), specializing in Industrial Electronics. You can reach Andrea at a.fontana@net2action.com.